Secure File Store
A small API for a remote filesystem that allows for uploading/removing files, sharing files among users, and revoking access to shared files. Its main features are its security guarantees. Specifically, it offers confidentiality and integrity - in other words, data placed in the server is inaccessible to anyone other than its uploader and the people they shared it with, and only the original uploader and the people they shared it with should be able to modify a file.
The API supports initializing and loading users, storing and loading files, appending to files, sharing and receiving files, and revoking access to files.
As a slightly more granular look at the security guarantees offered, the API operates under the following assumptions:
- The server containing the data is not trusted, and we should worry both about snooping/MITM attacks as well as the owner of the server being able to modify data stored
- There exists a server containing public keys which is trusted, and we have a secure channel connecting to them
- User passwords are secure (have good entropy)
- No state is saved other than that which is directly contained in a user’s profile, and that data should either be derivable from the user password or loadable from the data store
With these conditions, we get the following guarantees:
- All user names are kept confidential to the data store
- Upon loading a user (a user signs in again), if any of the user’s information required to re-initialize the user’s profile is modified or corrupted, an error will be returned.
- If not under attack by the data store or another user, retrieving a file will return the most recent version of the file uploaded by the file’s owner or another user they shared the file with
- Even when under attack, retrieving a file will never return an incorrect value - defined as a value other than the most recent version uploaded, or a previous version uploaded by the owner or another user they shared the file with
- When a file is stored, nobody other than the file’s owner should be able to learn full or partial information about the filename or data, other than the length of the data
- Every user a file has been shared with will be able to see updates to that file immediately
- Once a file is revoked, no user other than the original owner will be able to see updates to the file, nor will they have any information about updated or re-uploaded files other than its name
One notable thing that is not guaranteed is rollback resistance - the data store or a malicious user may be able to revert a file to its previous version. If a user then tries to retrieve a file, they may receive an outdated version. This is a consequence of the data store being stateless. In an actual file store, this would not be acceptable, but for the purposes of this project it was a good enough compromise. The purpose of this project was mainly to see how cryptographic primitives may be used in an actual system, not implement one from scratch to use (which is almost universally a terrible idea when it comes to security).
